Just find that installing friendly_id, only adding it in gemfile, was the reason of this issue.
I think I can close this one.
I opened an issue on friendly_id repo.

Rails 5.0.0.rc1, same issue, no friendly_id

This is due to initialization order. Any plugin that loads AR will cause it to pull config to AR::Base so subsequent initializers will be too late in the game to take effect.

Try setting this in config/application.rb instead or setting ActiveRecord::Base.belongs_to_required_by_default = true instead of Rails.application.config.active_record.belongs_to_required_by_default.

@jeremy thanks! But default rails initializer should be changed accordingly then so it won't confuse people in this situation

Agree @sandfoxme. Up for submitting a PR?

@jeremy ok, maybe tomorrow

Actually I'm confused on how to fix this. Just changing initializer to ActiveRecord::Base.belongs_to_required_by_default = true seems not good enough

p.s. and the issue should be reopened

This issue bit me today after upgrading to RC2. Setting ActiveRecord::Base.belongs_to_required_by_default solved the issue for me. When I upgraded, I removed config/initializers/active_record_belongs_to_required_by_default.rb in favor of config/initializers/new_framework_defaults.rb. Adding that file back and simply setting Rails.application.config.active_record.belongs_to_required_by_default also solved the issue. In my mind that supports the "initialization order" issue. Happy to work on a PR to help this if anyone has thoughts on where to start.

In my case, specifically, it seems like the Devise initializer caused the issue. Moving it to the bottom of the order (z_devise.rb) alleviated the issue.

While I agree that we can fix this issue it is more a plugin/gem not playing nice with the rails hooks. I'll take care of fixing it in devise and if you can try to find which gem/plugin is doing it please open an issue.

Also ran into this issue (I think its this issue) when installing the paranoia gem:
rubysherpas/paranoia#335

Narrowed it down to the fact that it is re-opening ActiveRecord::Base.

I suppose the question is where should this issue be fixed? Should gems not being re-opening ActiveRecord::Base? Should this be fixed in Rails?

I only picked this up because my specs for required behaviour stopped passing after I installed the gem (pro-tip: always write specs for important behaviour even if the framework does it by default).

You can reproduce this behaviour by simply re-opening ActiveRecord after loading Rails but before loading gems:

# application.rb
require 'rails/all'

class ActiveRecord::Base
end

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

My current preferred workaround for this issue, if caused by a gem, is to disable auto-require in your Gemfile:

gem 'paranoia', require: false

Create a new initialiser in which you require any libraries that re-open ActiveRecord

# z_paranoia.rb
require 'paranoia'

This ensures that it gets loaded after the configuration is set.

I suppose the question is where should this issue be fixed? Should gems not being re-opening ActiveRecord::Base? Should this be fixed in Rails?

This should be fixed in the gems.

There is no problem in re-opening ActiveRecord::Base but they need to do in the right way.

See heartcombo/devise@c2c74b0 on how they should be doing this.

Many gems re-open ActiveRecord::Base so I think there should be at least bad behavior detection with a warning, otherwise we have incorrect state without any clear sign of it

Should we not refer to model classes in initializers (to reference constants, e.g.)? Doing so in an early initializer seems to break active_record_belongs_to_required_by_default as well.

Should we not refer to model classes in initializers (to reference constants, e.g.)?

It is not recommended, no. This not just breaking the hooks but also can connect to database when you should not be connecting.

I think there should be at least bad behavior detection with a warning, otherwise we have incorrect state without any clear sign of it

👍. This is something that we should have. If you want please submit a pull request.

I'm closing since this is no much we can do here.

Reposting my comment from #27844 just in case anyone here might find it helpful:

If anyone else is having this same issue, I "fixed" it by removing the active_record_belongs_to_required_by_default.rb initializer and adding the line self.belongs_to_required_by_default = true to my ApplicationRecord.

Really, this fixes the symptom rather than the problem - I'm not sure what's causing the initializer to not be loaded probably; it's probably one of my gems. But the above hack is good enough for now.

To find out which gem is calling ActiveRecord before Rails has initialized, add the following line to config/application.rb before Bundler.require(*Rails.groups):

  ::ActiveRecord = 1

To figure out where issue comes from, better follow advice in #39855 (comment) and similar for ActiveJob #37030 (comment)

Basically ActiveSupport.on_load(:active_job) { puts caller } and possibly some puts calls to see at which point some particular initializer is being executed.